Subject: Names in ACTPU/ACTLU: better alternative

From: David Bryant/HQ/3Com <[email-masked]>
Date: 19 Dec 95 10:13:59 EDT

Derek - 

Thanks for straightening me out on SNACOM.   I think the XID3 approach still 
has some drawbacks (irrespective of the mapping issues).  For example XID3 
support would require an XID3 support engine (code) which is not always present 
or desirable in low end equipment (e.g. remote office routers, FRADs, etc.). 

Better yet, I think I've got a much better solution!  How about if we allow the 
PU to request it's name on RSP(ACTPU)?  This in-turn would imply a request for 
LUnames on subsequent ACTLU.  We can find bits as necessary in RSP(ACTPU) 
format 1.   And we'd have to create a new RU or NMVT to send the PU name on.   
This would only impact VTAM (instead of VTAM and NCP).  New PU code could 
support this option if desirable, and spoofing devices (DLSw, FRADs, PU2 
Gateways, etc.) could easily snoop the SSCP-PU sessions for this traffic. 

I would suggest that we also pursue the XID3 solution for T2.1 level nodes as 
it is cleaner to piggy back the PUname on ACTPU.

What say folks to this idea??

-dB

---

From: "Derek W. Bolton" <[email-masked]>
Date: Wed, 20 Dec 95 10:39:42 EST

Dave, 

> ... I think the XID3 approach still has some drawbacks (irrespective
> of the mapping issues).  For example XID3 support would require an
> XID3 support engine (code) which is not always present or desirable
> in low end equipment (e.g. remote office routers, FRADs, etc.).

It really doesn't need to be very complicated.  You can do it just
sending a fixed XID3 - negotiation proceeding, secondary, TGN=0, ...
If you want to make use of the received maxframe/maxin fields you can,
but if you don't you're no worse off than using XID0.

All you need to do is to resend the XID each time you receive one, or
on timeout, until connection occurs.  In fact, much the same as with
XID0.  Just about the only state info you need is cmd/rsp owed.

> Better yet, I think I've got a much better solution!  How about if
> we allow the PU to request its name on RSP(ACTPU)?  This in-turn
> would imply a request for LUnames on subsequent ACTLU.  We can find
> bits as necessary in RSP(ACTPU) format 1.  And we'd have to create a
> new RU or NMVT to send the PU name on.  This would only impact VTAM
> (instead of VTAM and NCP).  New PU code could support this option if
> desirable, and spoofing devices (DLSw, FRADs, PU2 Gateways, etc.)
> could easily snoop the SSCP-PU sessions for this traffic.

Yes, that's not bad.  Strictly speaking it wouldn't require a new NMVT
- VTAM could merely resend the ACTPU but with the PU name wrapped in a
vector NCP won't look at (in addition to the one that will be
stripped).  VTAM would need to remember that it had done this, not
only to avoid repeating the cycle on the next RSP(ACTPU) but also to
add a second copy of the LU name to the ACTLUs.

You say that using a separate NMVT has the advantage of no NCP change,
but to keep that advantage the same technique would have to be used
for the LU names.  Is that getting a bit messy?

> I would suggest that we also pursue the XID3 solution for T2.1 level
> nodes as it is cleaner to piggy back the PUname on ACTPU.

> What say folks to this idea??

Regards,
  Derek

---

From: [email-masked] (Dave Finnie)
Date: Wed, 20 Dec 1995 12:30:03 +1100

Dave's latest suggestion with Derek's modification sounds like
a really good compromise to me that should work (provided it
is ok with the VTAM/NCP guys).

Dave